home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960715-19961006 / 000093_news@columbia.edu _Sun Jul 28 17:02:23 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  7KB
  1. Return-Path: news@columbia.edu
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id RAA10551 for <kermit.misc@watsun.cc.columbia.edu>; Sun, 28 Jul 1996 17:02:22 -0400 (EDT)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id RAA04892 for kermit.misc@watsun; Sun, 28 Jul 1996 17:02:20 -0400 (EDT)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc,comp.dcom.modems
  7. Subject: Re: Problem getting 28800 bps in C-Kermit 5A(190) on a v.34 internal
  8. Date: 28 Jul 1996 21:01:59 GMT
  9. Organization: Columbia University
  10. Lines: 109
  11. Message-ID: <4tgkg7$fiv@apakabar.cc.columbia.edu>
  12. References: <CROTEN.96Jul24005129@crl.crl.com> <CROTEN.96Jul27005455@crl.crl.com> <CROTEN.96Jul27022451@crl.crl.com> <1996Jul28.193939.943@ia-us.com>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14. Keywords: kermit, flow control
  15. Xref: news.columbia.edu comp.protocols.kermit.misc:5665 comp.dcom.modems:145906
  16.  
  17. In article <1996Jul28.193939.943@ia-us.com>,
  18. Glenn Herteg <glenn@lia.com> wrote:
  19. : >In conclusion .. "set dial speed-matching off" makes things WORSE .. a LOT 
  20. : >worse.  
  21. : 
  22. : What you describe are all symptoms of the same problem I'm seeing, which is
  23. : that Kermit does not cope gracefully (ahem) with broken flow control.  I
  24. : wouldn't mind so much, except that its attempted recovery can often result
  25. : in a corrupted file getting transferred -- yep, the right number of bytes
  26. : in the file at the receiving end, and kermit claims it's done, but a UNIX
  27. : "sum" at both ends reveals the file didn't make it across intact.  And this
  28. : is in spite of using Block Check 3 for checksumming packets!  I had somebody
  29. : tell me the chances of this happening were 1 in {large number}; but sorry,
  30. : folks, it happens in a macroscopic percentage of the time (half the time,
  31. : perhaps?) on multi-megabyte files, under conditions I'll describe.
  32. : 
  33. Isn't this the kind of thing you should report to us when it happens, rather
  34. than letting it fester for ...
  35.  
  36. : I have a Sun-3/80 running C-Kermit 5A(189), 30 June 93... 
  37. :
  38. ...three years?  Note that the current version is 5A(190), October 1994,
  39. and that version 6.0 is in Beta test.
  40.  
  41. (Long story deleted...)
  42.  
  43. : ...  I've learned that if the transfer gets into this state but eventually
  44. : completes, the received file *must* be checksummed for integrity outside
  45. : of Kermit, because the Block Check 3 on the packet level was inadequate to
  46. : ensure a reliable transfer.
  47. : 
  48. There was a bug in version 5A(189) in this area.  Under a certain set of
  49. circumstances, corruption could occur at the PRESENTATION layer (i.e. above
  50. the datalink layer, where the block check is applied).  It was corrected in
  51. version 5A(190).  So try version 5A(190) and if you see anything like this
  52. happen again, please report it immediately to kermit@columbia.edu.
  53.  
  54. : This circumstance raises a design issue for future versions of Kermit.
  55. : There ought to be a way to perform a separate checksum algorithm over the
  56. : entire file at each end of the transfer, and have these secondary
  57. : checksums compared once the transfer is complete.  This ought to be
  58. : automated as part of the protocol, if only under control of some new
  59. : option.  Right now, I cannot trust any large transfer without checking
  60. : manually.
  61. :
  62. You should be able to trust it, period.
  63.  
  64. Of course I have thought about ex-post-facto checksumming, but it could be
  65. used only in a very restricted set of cases:
  66.  
  67.  . The transfer was in binary mode.  Obviously text-mode transfers can't
  68.    be compared in this way because text transfer mode implies conversions.
  69.  
  70.  . The two file systems are the same.  The idea of checksumming a file
  71.    implies that you have a simple UNIX-like stream file system.
  72.  
  73. But if those two cases hold true, you can have all the checksumming you want
  74. anyway, using UNIX utilities and a C-Kermit script:
  75.  
  76. define ARG1 return \%1                  ; Returns first argument
  77.  
  78. define SUMSEND -                        ; Send and compare checksums
  79.   open !read sum \%1,-                  ; Get checksum of local file
  80.   if fail end 1 \%1: Can't sum,-        ; Can't, fail
  81.   read \%a,-                            ; Read it into a variable
  82.   close read,-                          ; Close the "sum" process
  83.   assign sum1 \fexec(arg1 \%a),-        ; Get the first "word" of sum
  84.   set file type binary,-                ; Use binary transfer mode
  85.   send \%1,-                            ; Send the file
  86.   if fail end 1 \%1: Transfer failed,-  ; Check for failure
  87.   remote host sum \%1 > /tmp/sum2,-     ; Get sum on remote end
  88.   get /tmp/sum2,-                       ; Bring it here
  89.   if fail end 1 sum2: Can't get,-       ; Check for failure
  90.   remote delete /tmp/sum2,-             ; Delete the remote sum file
  91.   open read sum2,-                      ; Open it
  92.   if fail end 1 sum2: Can't read,-      ; Check for failure
  93.   read \%a,-                            ; Read it
  94.   close read,-                          ; Close it
  95.   delete sum2,-                         ; Delete it
  96.   assign sum2 \fexec(arg1 \%a),-        ; Get the first word of the sum
  97.   if = \m(sum1) \m(sum2) end 0,-        ; If they are equal, succeed
  98.   end 1 Checksums do NOT agree          ; Otherwise fail and print message
  99.  
  100. Version 5A(190) is required for this.  In version 6.0 it can be simplified
  101. quite a bit.  Put these two definitions in your .mykermrc file, and use
  102. SUMSEND instead of SEND when you want to send a file in binary mode and
  103. compare the checksums afterwards.  Requires a Kermit server on the far end
  104. and (of course) a "sum" program on each end.
  105.  
  106. In the meantime, I do agree that some sort of ex-post-facto confidence check
  107. would be a good thing, and will consider adding it to a future release.
  108. Probably this will take the form of one or more \v(xxx) variables, which could
  109. be conveniently used in client/server arrangements such as:
  110.  
  111.   send blah
  112.   remote query kermit checksum
  113.   if not = \v(query) \v(checksum) stop 1 Checksum mismatch
  114.  
  115. Also, with regard to your comment that C-Kermit does not handle massive data
  116. loss gracefully -- well, I'll bet it handles it better than any other file
  117. transfer protocol you can think of :-)  Nevertheless, there will be some
  118. additional improvements in the next Beta edit of C-Kermit 6.0 in precisely
  119. this area.
  120.  
  121. Watch this space for announcements.
  122.  
  123. And thanks for the (belated) report.
  124.  
  125. - Frank